Remote mirroring in storage systems is used to replicate logical volumes of a primary (also called ‘local’) storage system to a secondary (also called ‘remote’) storage system. In asynchronous remote mirroring, batches of updates are periodically sent to the remote site. The batches of updates are performed in cycles, wherein in each cycle the local system determines the changes that occurred in the logical volume to be replicated, since the previous cycle and transmits the changes to the remote site.
Snapshots can be taken in the local system upon starting a new cycle and the updates to be transmitted to the remote site in the new cycle are determined by comparing successive snapshots. The local system sequentially transmits all the determined updates to the remote site. Upon completion of the cycle, a snapshot of the mirrored volume may be taken at the remote system to reflect a valid replica of the local volume and can be used for restoring a compatible and consistent state of the mirrored volume, in case of a restart after failure of the remote system.
Snapshots are associated with data that is stored in the storage system while consuming physical resources such as storage space. Upon creation, the snapshot shares the physical space of the source volume (from which the snapshot was taken), until physical blocks of the source volume are written to and cannot longer be shared with the snapshot. When blocks of the source volume are updated, according to one technique, called copy-on-write, the blocks to be updated are copied to a new physical space before being overwritten by new data of the source volume, and the new physical space is now associated only with the snapshot and not shared with the source volume. According to another technique, no copy is performed before the update, but only pointer manipulation is used: the snapshot continues to refer to the old unchanged blocks, while the source volume refers to new address of blocks, where the new data is written. In either case, after the update, the source and the snapshot no longer share a physical copy of the changed blocks. The longer the snapshot exists and the source volume is kept being updated, the more physical space will be consumed by the snapshot alone.
There is a growing need to reduce the allocation of physical resources to snapshots.